Communication schedules are necessary in order to define clear and unique time-triggered communication within a distributed, time-triggered real-time computer architecture, hereinafter referred to as a “cluster.” Distributed, time-triggered real-time systems are used, inter alia, in automobiles or aircraft. Such systems are described, for example, in the following documents: U.S. Pat. Nos. 5,694,542; 4,866,606 and 5,887,143; European Patent No. 1,222,542 B1; and World Patent Publication Nos. WO 2002/099643 A3 and WO 2004/0233302.
Bus protocols for distributed, time-triggered real-time systems are further described in: TTP: “TTP/C Protocol Specification”, available on http://www.tttech.com; FlexRay: “FlexRay Communication System Protocol Specification”, available on http://www.flexray.com; and “TTCAN (time-triggered communication on CAN)”, ISO 11898-1. Detailed information concerning communication schedules are also available in: Kopetz, H. (1997)—“Real-Time Systems, Design Principles for Distributed Embedded Applications”, ISBN: 0-7923-9894-7, Boston, Kluwer Academic Publishers; and Kopetz, H., Bauer, G.—“The Time Triggered Architecture”, Proceedings of the IEEE Vol. 91, No. 1, Jan. 2003, pp. 112-126.
The following short definitions are provided with reference to the terminology used.                “Communication schedule” Contains the sum of all parameters that are necessary for the unique determination of time-triggered communication. These consist of at least the following:                    Size of the slots, allocation of the transmitter nodes for all slots            Number of the communication rounds            Bit position and length of all individual messages within a slot            Additional protocol-dependent parameters, such as, for example, the length of the waiting periods between slots                        “Cluster communication schedule” The parameters for this are complete and are thus available for all nodes in their entirety—unlike the node communication schedule.        “Node communication schedule” This refers to those parameter subsets of a communication schedule that are adequate to configure a node and make it capable of communication.        “Slot” A period of time in time-triggered communication, which is allocated uniquely to a specific node. Only this particular node may send messages within this time period.        “Cluster” An abbreviated term for a distributed, time-triggered real-time system consisting of nodes and the communication system via which the nodes can exchange messages in accordance with the communication schedules.        “Node” Integrated, electronic computer. A node communicates with other nodes in the same cluster via a time-triggered communication channel.        “Grid” This term is used in the context of the invention for a meta-communication schedule. It refers to the sum of the parameters that are necessary to establish compatibility between various communication schedules within the scope of the present invention.        “Invariant component” For the purposes of the invention, this term refers to a node that can be used unchanged in various clusters implementing the same software and the same nodal communication schedule.        “Cluster variant” A cluster variant is a variant of another cluster if the cluster variant and the original cluster have at least one common node type (invariant component).        
If, for example, clusters are used in an automobile, then the individual nodes are associated with different individual applications, such as, for example, engine control, control of the air-conditioning system, control of seat adjustments, exhaust purification, etc. If an automobile is to be offered with different equipment and fittings, then it becomes necessary to use cluster variants, which, however, leads to variations in the communication schedules. Thus, the same nodal computers must have, in different variants, different communication schedules so that they do, in fact, differ from one another. This leads to undesirable complications and costs with the large-scale production of cluster variants, since it must either be possible to subsequently load the communication schedules into the nodal computers, or a node variant must be provided for each cluster variant. The process of loading the communication schedules must normally be done on the production bench and costs time and leads to logistic problems. The provision and storage of various node variants for each cluster variant naturally leads to costs in a similar manner.
It is therefore necessary to find means of using invariant components that can be applied without any modification to different cluster variants. In principle, nodal computers can also communicate when their communication schedules do not exactly reflect the specific cluster. Communication can work as long as all communication partners of the node transmit and receive messages in conformity with the schedules of the node.